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SUMMARY 


1.  Problem  and  Background 

For  major  item*  of  equipment  (i.e.  RICC  1 end  2)  loss  end  lose 
recovery  date  are  needed  to  help  substantiate  current  world- vide  asset 
position  (WWAP)  of  Army  stocks.  Furthermore,  loss  data  are  used  in 
projecting  future  requirements  on  vhlch  budgets  and  distribution  of  stocks 
are  based.  Thus,  there  is  a need  for  loss  and  loss  recovery  data.  The 
problem  is  that  there  is  no  viable  system  today  to  provide  these  data. 

The  Army's  present  system  for  reporting  retail  level  loss/loss 
recovery  data  for  RICC  1 and  2 items  is  described  in  AR  710-3,  Chapter  4. 
Experience  shows  that  this  system  has  many  problems.  Some  of  these  are: 
gaps  in  system  coverage;  apparent  duplications  and/or  voids  in  the  data; 
questionable  quality  of  data;  and  use  of  non-standard  coding  structures. 
Above  the  retail  level,  transaction  histories  are  suomltted  to  the  Major 
Item  Data  Agency.  These  transactions  contain  loss  and  loss  recovery 
information  and  are  processed  for  purposes  of  the  Continuous  Balance 
System  (CBS),  which  is  a new  way  to  arrive  at  the  WWAP  (see  reference  1). 
They  are  not  processed  to  provide  requisite  loss/loss  recovery  data  for 
other  applications  such  as  projecting  requirements  because  this  possibility 
has  not,  until  now,  been  investigated. 

2.  Objectives 

a.  To  determine  what  type  of  loss/loss  recovery  data  are  needed. 

b.  To  develop  a system  to  provide  these  data. 

3.  Scope  and  Limits 

This  study  applies  to  principal  items  covered  by  Chapter  4,  AR  710-3. 

It  considers  a loss/loss  recovery  reporting  system  to  provide  data  needed 
for  computing  replacement/consumption  factors,  the  Army  Materiel  Plan  (AMP), 
the  Major  Item  Distribution  Plan  (MIDP),  and  the  World-Wide  Asset  Position 
(WWAP). 
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4.  Methodology 

a.  Examine  what  types  of  loss/loss  recovery  data  are  needed. 

b.  Analyze  the  reporting  system  of  Chapter  4,  AR  710-3. 

c.  For  each  system  that  feeds  transaction  histories  to  MIDA  for  CBS 
purposes,  determine  if  all  I099  and  loss  recoveries  are  included  among 
the  transactions  and  if  there  are  duplications. 

d.  Determine  what  new  procedures  or  modifications  to  existing 
procedures,  systems,  and  regulations  are  needed. 

5.  Findings 

a.  The  reason  for  a loss  is  required  information.  Eight  loss  cate- 
gories are  adequate  for  this  purpose.  These  categories  are:  replacement/ 

consumption  type  1,  rcplacenent/consuraption  type  2,  proof  test,  conversion 
disposal,  transfer,  physical  inventory  and  other.  The  two  types  of  re- 
placcment/consunptlon  losses  are  to  distinguish  issue  losses,  such  as 
uneconomically  reparable  stock  issued  to  PDO,  from  adjustment  losses  such  as 
adjustment  for  stock  unaccountably  lost  in  the  field.  Although  these  loss 
categories  appear  to  be  self-explanatory,  it  is  difficult  to  assign  a unique 
category  to  a loss  without  a decision  tree  that  clearly  defines  each  category. 
Such  a decision  tree  is  given  in  Chapter  2.  The  information  needed  about 

a loss  recovery  is  minimal. 

b.  HIDA  has  a pre-processor  for  transactions  from  every  system  that 
feeds  CBS.  The  output  from  the  pre-processors  are  standard  records  that 
can  be  subsequently  processed  to  provide  loss/loss  recovery  data  by  the 
required  loss  categories. 

6.  Conclusions 

Requisite  loss/loss  recovery  data  can  be  had  as  a by-product  of  CBS. 
Transaction  reporting  for  purposes  of  CBS  can  be  expanded  to  cover  all 
property  accounts.  However,  some  manual  reporting  is  required  on  an 
interim  basis  to  provide  the  transaction  input. 

There  are  operational  system  deficiencies  that  might  have  an  adverse 
affect  on  the  quality  of  the  loss/loss  recovery  data.  Chapter  4 addresses 

the  problem  and  suggests  possible  solutions. 
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CHAPTER  I 


CURRENT  SYSTEM  aKD  PROBLEMS 

1.1  Reporting  Universe 

Th«  reporting  universe  esn  be  subdivided  Into  three  levels:  wholesale, 

intermediate,  and  field.  For  purposes  of  this  .report  these  levels  ere 
defined  as  follows: 

a.  Wholesale  - stock  under  NICP  accountability. 

b.  Intermediate  level  - stock  under  the  accountability  of 

FORSCOM/TRADOC  installations  and  overseas  ICP's. 

c.  Field  level  - all  other  Army  accounts. 

The  field  level  consists  of  retail  accounts  and  user  accounts.  Retail 
accounts  are  the  Installation  property  book  (PB)  and  stock  record  accounts 
(SRA)  of  non  FORSCOM/TRADOC  Installations.  They  Include  the  Army  Reserve, 
National  Guard,  ROTC,  hospitals  of  the  Health  Service  Command,  depots, 
arsenals,  laboratories,  proving  grounds,  ammo  plants,  home  sites  of  the 
NICP's,  Military  District  of  Washington  (MDW) , and  miscellaneous  activities 
such  as  US  Military  Academy.  User  accounts  are  other  than  Installation 
accounts  and  Include  accounts  such  as  PB  of  company  and  battalion  units  and 
SRA  of  direct  support /general  support  units. 

1.2  Description  of  Loss/Loss  Recovery  Reporting  Above  the  Field  Level 

At  the  wholesale  and  Intermediate  level  there  Is  no  loss/loss  recovery 
reporting  per  se.  Instead,  the  NICP's,  overseas  ICP's,  and  FORSCOM/TRADOC 
installations  submit  transaction  histories  to  MIDA  for  processing  as  needed 
for  the  Continuous  Balance  System  (CBS).  The  CBS,  Incidentally,  la 
described  In  reference  (6)  and  (7).  The  transaction  histories  contain 
all  the  transactions  that  transpired  since  the  last  submission.  These 
transactions  are  Input  to  a pre-processor  which  creates  a standard  record 
for  each  transaction  that  increases  or  decreases  the  stock  balance. 

A portion  of  the  standard  record  la  made  up  of  data  elements  created 
by  the  CBS  pre-processor.  Among  the  data  elements  created  la  the  CBS 
transaction  code,  which  Identifies  the  type  of  transaction.  For  example. 
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code  50  1b  a loss/lott  recovery  transection  while  code  30  lo  a shipment  from 
transection.  The  rest  of  the  record  hes  data  that  are  perpetuated  flora  the 
original  transaction.  Not  all  of  the  data  elements  in  the  original  trans- 
action are  perpetuated  in  order  to  keep  the  standard  record  small.  However 9 
data  elements  that  are  needed  to  identify  a loss/loss  recovery  transaction 
are  perpetuated.  These  are:  document  Identifier  code,  fund  code,  management 

coda,  condition  code,  ownership/purpose  code,  document  number,  supplementary 
address,  suffix  code,  and  quantity.  M1DA  has  a pre-processor  for  each 
system  that  feeds  these  transactions.  For  the  wholesale  level  there  is  a pre- 
processor for  ALPHA  transactions  for  the  NICP*s  now  on  ALPHA  (AVSCOM,  TROSCOM 
and  HICOM)  and  one  for  each  NICP  ..ot  now  on  ALPHA  (ARMCOM,  ECOM  and  TACOM) . 

For  the  intermediate  level  there  are  four  pre-processors:  SAILS,  BASOPSi, 

USAMMAE  (Europe),  and  3S  (USARPAC  sub-commands). 

1.3  Description  of  Loss/Loss  Recovery  Reporting  From  the  Field  Level 

Some  retail  accounts  (e.g.  National  Guard)  submit  transactions  to 
MIDA  for  CBS  purposes.  MIDA  has  a pre-processor  to  process  these  trans- 
actions in  a manner  similar  to  the  transaction  processing  described  in 
the  previous  section.  MIDA  also  has  pre-processors  to  process  trans- 
actions from  Just  about  all  of  the  retail  accounts  that  do  not  presently 
subralt  transactions.  Efforts  are  underway  to  include  these  accounts 
in  transaction  reporting.  For  the  user  accounts  MIDA  has  no  pre-processors 
at  this  time. 

Presently,  all  field  level  accounts  are  required  to  report  under  the 
system  described  in  Chapter  4,  AR  710-3.  Those  retail  Accounts  that  submit 
transactions  are  not  excluded.  Briefly,  at  the  time  a loss  or  loss 
recovery  is  posted  to  the  accountable  record,  the  accountable  officer  pre- 
pares DA  Form  3906  in  three  copies.  Copy  1 is  forwarded  to  the  activity 
that  maintains  the  local  command  flic  (this  copy  is  used  in  updating  the 
equipment  status  reports);  copy  2 is  retained  in  the  accountable  property 
voucher  file;  and  copy  3 is  forwarded  to  the  administrative  processing  ele- 
ment of  the  local  command  who,  in  turn,  forwards  the  copy  directly  to  MIDA  * 
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if  the  local  command  does  not  have  or  does  not  receive  ADP  support * or  to 
the  supporting  Data  Processing  Installation  (DPI)  otherwise.  In  case  of  the 
latter*  the  DPI  transcribes  the  data  on  a tape  or  card  and  forwards  the 
tape  or  cards  to  MIDA  via  fastest  available  Deans*  e.g.*  transceiver. 
Specified  time  francs  for  copy  3 are  these:  one  day  fron  else  of 

preparation  of  DA  Form  39G6-R  to  tine  of  forwarding  to  the  administrative 
processing  element;  one  day  for  processing  by  the  administrative  element; 

3  days  for  processing  by  the  ADP  activity.  Thus*  excluding  intransit 
times*  MIDA  should  receive  the  loss/loss  recovery  report  within  five  days. 
Incidentally*  If  the  loss  is  Incident  to  shipment,  DA  Form  3906-R  Is  pre- 
pared by  the  shipping  officer  Instead  of  the  accountable  property  officer. 

Use  of  the  following  loss/loss  recovery  codes  Is  specified  In 
Chapter  4,  AR  710-3: 

a.  Loss  codes  for  losses  not  Incident  to  shipment  - 

1 - Combat  loss. 

2 - Fair  wear  and  tear  (FWT) 

3 - Pilferage/theft/storage. 

4 - Crash/accldent/act  of  Cod. 

5 - Modification/conversion. 

6 - Washout. 

7 - Transfer. 

b.  Loss  codes  for  losses  Incident  to  shipment  - 

7 - Ship  sinking. 

8 - Other  than  ship  sinking. 

c.  Lose  recovery  codes  - 

A - applies  to  recoveries  of  losses  reported  as  type  1 through  5* 
and  stock  found  on  post  that  was  not  previously  reported  as  a loss. 

8 - Recovery  of  a loss  reported  as  type  6 or  7 loss  not  Incident 
to  shipment. 
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1.4  Problems 


Experience  shows  that  the  reporting  system  of  Chapter  4,  AR  710-3, 
which  became  effective  In  December  1972,  Is  not  working.  The  Army  Audit 
Agency  h«*s  audited  several  installations  with  similar  findings;  some 
legitimate  losses  are  not  being  reported  while  other  transactions  that 
are  not  losses  are  being  reported  as  losses.  Reference  (9)  is  a typical 
report.  There  Is  also  evidence  that  some  activities  do  no  reporting 
at  all  because  they  are  unaware  uf  the  reporting  requirements.  The  MIDA 
Technical  Assistance  Team  has  made  some  on  site  investigations  of  nine 
TRADOC  installations  and  found  that  as  of  December  1974,  approximately 
62Z  of  the  432  TOE  units  queried  were  not  aware  of  the  reporting  system. 

Only  part  of  this  problem  can  be  explained  by  the  fact  that  six  of  the 
nine  Installations  Investigated  had  no  Implementing  instructions.  For 
the  installations  that  had  issued  implementing  instructions,  approximately 
J2Z  of  the  active  Army  field  units  were  unaware  of  the  reporting  system. 

More  on  this  ca.i  be  found  In  Reference  (8). 

When  the  Chapter  4,  AR  710-3  reports  do  come  in,  some  of  the  reports 
cannot  be  processed  at  MIDA  because  the  coding  is  not  as  specified  in 
the  regulation.  In  these  Instances  MIDA  makes  an  effort  to  contact  the 
delinquent  units  for  the  information  they  need  to  process  the  loss  report. 

This,  however,  requires  a considerable  amount  of  effort  and  causes  delays. 
There  have  also  been  some  Instances  of  duplicate  reports. 

Our  analysis  points  out  that  reporting  unaer  Chapter  4,  AR  710-3  has 
weaknesses;  It  is  difficult  and  can  lead  to  duplications.  The  regulation 
does  not  recognize  that  there  are  two  types  of  losses:  those  with  turn-ins 

(e.g.  fair  wear  and  tear)  and  those  with  no  turn-ins  (e.g.  abandonment,  theft). 
Losses  vlth  turn-ins  should  be  reported  at  time  of  disposition  and  not  at  time 
of  incidence.  Failure  to  recognize  this  is  what  makes  the  reporting  difficult 
and  can  lead  to  duplications.  Another  problem  is  that  the  regulation  does 
not  have  the  right  loss/loss  recovery  codes. 

The  test  phase  of  CBS  shows  that  transaction  reporting  is  promising. 
However,  processing  is  difficult  primarily  because  there  are  so  many 
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different  systems  feeding  transactions.  Future  standardizations  (i.e.  all 
of  the  wholesale  level  will  be  covered  by  ALPHA;  intermediate  level  by 
SAILS;  active  Army  field  level  by  SADLS  and  DS4;  non-active  Army  field 
level  by  systems  that  are  still  undetermined)  should  alleviate  this 
difficulty. 

Although  transaction  reporting  appears  to  be  working  well,  the  pro- 
blem is  that  these  transactions  are  not  processed  to  provide  requisite 
loss/loss  recovery  data.  This  possibility  had  not  been  previously  in- 
vestigated. It  was  not  known  whether  the  transactions  could  be  pro- 
cessed to  provide  the  requisite  data,  or  what  changes  were  needed  to 
make  the  transactions  suitable  for  this  purpose. 


CHAPTER  II 


PROPOSED  SYSTEM  FOR  KOS-l’SER  ACCOUNTS 

2.1  Introduction 

The  sponsor  expressed  Interest  in  a system  to  provide  fully  auditable 
loss/loss  recovery  data.  Our  Investigations  and  analysis  to  determine 
vhat  type  of  loss/loss  recovery  oata  are  needed,  and  our  analysis  of  the 
transactions  from  the  various  systems  that  feed  CBS,  Indicated  that 
auditable  loss/loss  recovery  data  can  be  had  by  merely  processing  purified 
transaction  data  provided  by  the  CBS  system.  That  Is,  auditable  loss/loss 
recovery  data  can  be  had  as  a by-product  of  CBS.  This  chapter  describes 
how  this  can  be  done  for  all  property  accounts  except  the  user.  The  next 
chapter  covers  the  user  property  accounts. 

2.2  Loss  Categories 

The  system  must  provide  a breakout  of  losses  and  loss  recoveries  by 
certain  categories.  Which  categories  are  required  was  discussed  with 
AMC  and  DA  (sec  reference  (10)).  Based  on  chose  discussions  and  our 
analysis,  we  determined  that  the  following  loss  categories,  combined  with 
the  other  data  elements  in  the  loss  data  file  (Section  2.5),  will  satisfy 
all  loss/loss  recovery  data  requirements  (i.e.  provide  requisite  data  for 
computing  replacement/consumption  factors  and  breakout  of  data  as  needed 
for  AMP  and  MIDP) • 

Replacetncnt/consunption  type  1 

Replacement /consumption  type  2 

Proof  test 

Conversion  (i.e.  assembly/dlsa6sembly/nodlf ication/ 
conversion) 

Transfer  (i.e.  sales  and  free  issues  to  non-Army 
customers) 

Disposal 

Physical  inventory 

Other 


Ideal  definitions  of  the  above  loss  categories  are  given  via  a 
decision  tree  in  Figure  2.2.1.  To  understand  the  figure,  "act  of ’God" 
oust  be  defined.  An  act  of  God  loss  is  any  loss  in  storage  due  to  fire, 
loss  due  to  an  accident  en  route  (e.g.  ship  sinking  or  plane  crash),  or 
loss  due  to  natural  disaster  to  include  flooding,  tornado,  hurricane, 
earthquake,  snow  damage,  etc.  The  only  field  level  losses  to  be  classified 
as  act  of  God  are  those  due  to  natural  disasters. 

Study  of  Figure  2.2.1  will  show  that: 

Replaccment/Consumptlon  Type  1 is  any  loss  that  occurs  to  a troop 
unit  account  (as  defined  in  AMP)  but  is  not  due  to  act  of  God  or  proof  test/ 
sampling;  it  did  not  occur  in  storage;  and  there  is  no  tum-in.  Since 
there  are  no  turn-ins,  this  category  Includes  only  adjustment  type  losses. 
Examples  are  adjustments  due  to  unaccountable  losses  in  the  field. 

Replacement /Consumption  Type  2 is  any  loss  of  an  uneconomically 
reparable  item  (erg.  MILSTRIP  condition  code  H or  P)  provided  that  this 
condition  was  not  the  result  of  contamination/deterioration  in  storage, 
or  act  of  God,  or  proof  test /sampling.  Since  this  loss  occurs  only  if 
there  is  a turn  in  (l.e.  a physical  remain)  it  Includes  only  issue  type 
los sea  to  PDO  or  to  assembly/dlsassembly/modlf lcatlon/converslon.  The  loss 
is  not  recognized  until  there  is  an  issue  transaction.  The  uneconomically 
reparable  item  may  or  may  not  be  obsolete. 

Proof  test  category  Includes  all  losses  due  to  proof  test/sampling. 
For  example,  the  loss  of  a tank  blown  up  in  testing  the  capability  of  a 
missile  is  a proof  test  loss. 

Physical  Inventory  category  includes  all  losses  that  occur  in 
storage.  The  causes  may  be  clerical  or  mechanical  error,  shrinkage, 
theft,  or  any  other  reason. 

Transfer  category  Includes  all  sales  or  free  issues  to  non-Army 
customers.  The  stock  may  be  obsolete  but  it  must  be  either  serviceable 
or  economically  reparable. 

Disposal  category  includes  all  Issues  of  serviceable  or  economically 
reparable  stock  to  PDO.  The  stock  may  or  may  not  be  obsolete. 
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Conversion  category  Includes  all  Issues  to  a6senbly/disassembly/ 
modification/conversion.  The  stock  issued  nay  or  ray  not  be  obsolete  but 
must  be  serviceable  or  economically  reparable. 

Other  category  Includes  all  losses  not  covered  by  one  of  the 
other  seven  categories. 

Several  comments  related  to  the  loss  categories  are  in  order.  The 
only  losses  that  should  be  used  in  computing  replacement /consumption 
factors  arc  the  replacer.cnt/consuraption  type  1 and  the  replacement /consumption 
type  2 losses.  Each  of  these  two  categories  includes  both  the  peacetime 
and  the  combat  replacement/consumption  losses.  Our  analysis  shows  that  sep- 
arate categories  for  combat  and  peacetime  losses  arc  not  necessary  because 
It  can  be  assumed  that  the  losses  are  peacetime  losses  and  can  be  used  in 
computing  peacetime  factors  if  they  arc  reported  either  during  tine  of 
peace , or  during  tine  of  war  but  from  an  account  that  is  in  a non-combat 
zone.  If  the  account  is  in  a combat  zone,  the  losses  will  be  mixed  but 
combat  losses  can  be  determined  by  subtracting  the  average  replacement/ 
consumption  losses  reported  during  time  of  peace  from  the  losses  reported 
in  time  of  war. 

We  have  no  separate  category  for  washout  (i.e.  phaseout)  losses.  Our 
analysis  indicates  that  this  category  is  needed  only  to  show  when  overage 
or  obsolete  items  will  be  washed  out  of  the  system.  The  projection  of 
washout  losses  is  based  on  the  age  of  existing  equipment  and  other 
data  such  as  the  state  of  the  economy,  but  not  on  past  washouts.  Since 
actual  losses  due  to  washout  are  not  used  in  forecasting,  and  there  is  no 
other  application  of  washout  data,  there  is  no  need  to  show  that  a loss 
is  a washout.  What  is  important  is  to  show  that  there  was  a loss.  In 
the  proposed  system,  washout  losses  are  shown  as  disposal  if  the  stock 
is  issued  to  PDO  and  as  conversion  if  the  stock  is  Issued  to  assembly/ 
disassembly/modificat ion/conversion. 

2.3  General  Description  of  System 

Figure  2.3.1  depicts  the  proposed  system.  Inspection  of  the  figure 
shows  that  the  proposed  system  is  nothing  more  than  three  data  processors, 
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namely v CBS  pre-processors * consolidation  and  loss/loss  recovery  processor. 
Furthermore*  two  of  the  processors  already  exist  and  are  used  in  CBS 
processing  of  transaction  data. 

Examine  the  system  step  by  step.  Army  wide  transactions  are  monthly 
inputs  to  the  pre-processors.  The  pre-processors  are  the  CBS  pre-processors 
used  to  purify  incoming  transaction  data  and  reformat  them  in  a more  con- 
venient form.  These  purified  and  reformatted  transactions  are  the  outputs 
from  the  pre-processors  and  are  labeled  "STANDARD  RECORDS"  in  Figure  2.3.1. 

Let  us  digress  for  a minute  to  amplify  on  the  pre-processors.  There 
lo  a CBS  pre-processor  for  each  ADP  system  feeding  transaction  data  to  CBS. 
They  are: 

a.  CCSS  (formerly  ALPHA) 

b.  SAILS 

c.  BASOPS 

d.  USAMMAE 

e.  3S  (WEST  PAC) 

f.  Modified  DLOGS 

g.  CCSS-ISA 

h.  TEAM  UP  - ISA 

i.  SPEEDEX  - ISA 

These  systems  cover  all  property  accounts  except  the  user  property  accounts. 
CCSS  covers  the  NICP  accounts.  SAILS  and  BASOPS  cover  the  Installation 
supply  accounts  of  the  FORSCOM/TRADOC  installations.  Transaction  histories 
from  these  Installations  also  include  the  Army  Reserve  stocks.  USAMMAE 
covers  the  ICP  accounts  in  Europe  while  3S  covers  the  ICP  accounts  of  the 
Pacific  area  sub -Commands  (e.g.  Japan*  Korea).  Modified  DLOGS  covers  the 
National  Guard  accounts*  while  CCSS-ISA*  TEAM  UP  - ISA*  and  SPEEDEX  - ISA 
cover  the  remaining  field  level  retail  accounts  as  explained  in  1.3. 

The  next  data  processor  is  consolidation.  This  processor  does  nothing 
more  than  to  consolidate  the  outputs  (i.e.  standard  records)  from  the  pre- 
processors. This  is  done  to  simplify  subsequent  CBS  processing.  The  output 

*ARMCOM,  TACOM  and  ECOM  are  not  yet  on  CCSS.  However,  since  all  three  are 
scheduled  to  be  on  CCSS  in  the  near  future*  we  do  not  give  special  con- 
siderations to  the  processing  of  transaction  data  from  these  NICP's. 
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FIGU1E  2.3.1:  LOSS/IOSS  RECOVERY  SYSTEM 
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from  this  processor  is  a file  labeled  "CONSOL  RECORDS"  in  the  figure, 
meaning  "consolidated  standard  records".  This  file  contains  purified 
and  reformatted  transaction  data  from  all  the  property  accounts  except 
the  users. 

Up  to  now  we  have  described  what  is  a portion  of  the  existing  CBS 
processing.  The  new  feature  is  to  take  the  output  (consolidated  records 
file)  from  this  CBS  processing  and  process  it  as  needed  to  provide  the  loss/ 
loss  recovery  data.  This  is  done  by  the  loss/loss  recovery  processor,  which 
is  the  final  data  processor  in  the  proposed  system.  The  figure  shows  that 
the  output  a f the  loss/loss  recovery  prucessor  is  the  current  loss  data  file. 
This  is  the  file  that  has  the  needed  data.  The  old  loss  data  file  is  shown 
as  the  other  input  to  the  processor.  This  is  merely  the  output  file  generated 
by  this  processor  in  the  p:  vious  quarter.  The  current  loss  data  file  has 
the  same  data  as  the  old  loss  data  file  plus  the  loss/Joss  recovery  data 
for  the  current  quarter. 

2.4  Losb/Loss  Recovery  Processor 

The  consolidated  records  file  contains  all  transactions  that  Increase 
or  decrease  the  balance  in  a property  account.  Not  all  incrases  are  loss 
recoveries  and  not  all  decreases  are  losses.  The  first  function  of  the 
loss/loss  recovery  processor  is  to  reduce  this  file  by  eliminating  those 
transactions  that  are  not  losses  or  loss  recoveries.  All  minus  transactlone 
are  losses  except  - 

a.  lateral  transfers  (i.e.  issues  to  other  Army  customers). 

b.  catalog  adjustments  (i.e.  adjustments  in  purpose  code,  condition 
code,  and  NSN  changes  due  to  AMDF  broadcasts). 

c.  reversed  transactions.  For  example,  an  issue  to  PDO  is  a minus 
transaction.  If  there  is  no  reversal  of  this  issue  transaction,  the  trans- 
action is  a loss . If  there  is  a reversal  transaction  for  this  issue,  the 
issue  is  not  a loss. 

All  plus  transactions  are  loss  recoveries  except  - 

a.  lateral  transfers  (i.e.  receipt  from  another  Army  account). 


17 


b.  gains  from  procurement  or  local  fabrication. 

c.  catalog  adjustments. 

d.  reversed  transactions.  For  example!  a gain  from  PDO  is  not 

a loss  recovery  if  this  transaction  has  an  offsetting  reversal  transaction. 

For  the  transactions  that  are  loss  or  loss  recoveries  the  processor 
then  determines  what  type  of  a loss/loss  recovery  the  transaction  is  and 
assigns  a code  corresponding  to  the  loss  category  (see  2.2).  The 
rationale  to  do  this  has  already  been  developed  and  is  documented  in  a set 
of  tables  (Section  2.6)  that  can  be  programmed  in  the  loss/loss  recovery 
processor. 

The  processor  next  creates  a record  for  the  loss  data  file  and 
updates  this  file  by  adding  the  newly  created  records  to  the  loss  data 
file  and  purging  overaged  records  from  it. 

2.5  Loss  Data  File 

v*, 

The  AM?  has  the  most  stringent  data  requirements.  A data  base  that 
Is  adequate  for  AMP  will  be  adequate  for  computing  replacement/consumption 
factors9  the  MIDP,  and  the  WWAP.  Reference  (11)  describes  the  loss  data  v 

used  In  SAMP AM,  which  is  the  automated  system  for  computing  the  AMP.  The 
loss  data  file  described  here  is  designed  to  meet  the  aata  needs  in  SAMPAM. 

The  loss  data  file,  which  is  a file  created  by  the  loss/loss  recovery 
processor,  will  contain  a five  year  history  of  all  Army  wide  losses  and 
loss  recoveries.  The  history  will  be  built  up  gradually  and  will  be 
updated  at  quarterly  intervals.  If  experience  shows  this  to  be  Inadequate 
it  will  be  updated  at  monthly  Intervals.  The  file  should  have  at  least 
one  year  (most  current)  of  data  at  the  transaction  level  of  detail.  The 
rest  can  be  monthly  summaries  but  a transaction  level  of  detail  is 
preferred  because  it  would  provide  a greater  audlt/reconclliatlon  cap- 
ability in  the  event  this  is  needed,  and  a better  data  base  for  analysis 
purposes. 

The  data  elements  in  the  loss  data  file  record  are  shown  in  Figure 
2.5.1.  They  are: 

a.  Type  Record  Code  - indicates  whether  the  record  is  a loss 
or  a loss  recovery. 
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b.  Routing  Identifier  Code  - the  RIC  of  the  canaging  NIC? 

c.  SSN  - standard  study  number 

d.  NSN  - national  stock  number 

e.  RICC  - reportable  item  control  code 

f.  Loss  category  code  (also  applies  to  loss  recoveries): 

1 - Replacement /con sumption  type  1 

2 - Replacement  Consumption  type  2 

3 - Disporaj 

4 - Transfer 

5 - Physical  inventory 

6 - Conversion 

7 - Proof  test 

8 - Other 

g.  Quantity 

h.  Condition  code  - MILSTRIP  condition  code  or  blank.  If  this 
field  is  blank,  condition  code  A is  to  be  assumed  if  the  loss  category 

is  not  replacement/consumptlon  type  2 and  F if  it  is. 

i.  DODAAC  - DoD  activity  address  code  identifies  the  ship  to 
address.  This  code  is  applicable  only  to  transfer  and  disposal  losses. 

J.  Stratification  code  - identifies  the  CBS  stratification 
for  the  losing  account.  The  stratifications  are  subject  to  change  as  time 
dictates.  The  stratifications  currently  in  use  (see  reference  (1))  are: 


1. 

2. 

3. 

4. 


Europe 

Korea 

Japan 

Hawaii 


6. 

7. 

8. 

9. 

10. 


Panama 

Alaska 

STRAF 


11.  Other  CONUS  AA 

12.  ARNG 

13.  USAR 
CONUS  Depots 


k. 

Ft.  Jackson). 


F0RSC0M,  Other  14. 

5.  Thailand  10.  TRADOC 

CBS  data  source  code  - identifies  the  losing  account  (e.g.9 
This  data  element  will  be  helpful  in  reconciling  suspect 
data,  in  the  event  this  occurs,  or  in  restratifying. 

1.  Fund  code  - this  code  provides  the  capability  to  determine 
whether  the  loss  is 

a.  Not  reimbursable. 

b.  Reimbursable  with  funds. 

c.  Reimbursable  in  kind. 
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FIGURE  2.5.1:  LOSS  DATA  BANK  RECORD 


n.  Dace  of  transaction.  This  is  the  date  of  posting  the  loss 
to  the  accountable  record. 

2.6  Tables  for  Assigning  Loss  Categories  to  Transactions 

This  section  gives  nine  tables  for  assigning  loss  categories  to 
transactions.  There  is  one  table  for  each  AD?  system  that  currently 
feeds  transaction  histories  to  CBS.  There  is  only  one  table  for  the 
wholesale  level  even  though  several  ADP  systems  currently  feed  the  whole- 
sale level  transaction  data.  The  table  is  for  transactions  from  the  CCSS. 
It  is  expected  that  in  the  very  near  future  all  commodity  commands  will 
be  on  CCSS,  so  that  the  CCSS  system  will  be  the  only  system  feeding  whole- 
sale level  transaction  data. 

Minor  approximations  were  used  in  the  development  of  these  tables. 

The  approximations  are  discussed  in  Section  2.7. 

Data  elements  in  the  transactions  are  labeled  across  the  top 
(column  headings).  They  are: 

DIC  - document  identifier  code 
CC  - condition  code 
MC  management  code 
FC  - fund  code 

QIC  - quantity  identification  code  (this  is  used  in  the  BASOPS 
system  in  the- same  manner  as  condition  code) 

The  DIC  is  a three  character  code.  The  third  position  is  immaterial 
in  many  instances  and  is  either  omitted  or  shown  as  a dash  (-) . 

Suppl.  Add.  ■ A,D  refers  to  the  first  position  of  the  supplementary 
address  in  the  transaction.  This  identifies  an  issue  transaction  to 
assembly/disassembly  (see  AR  725-50). 

To  illustrate  the  tables  look  at  Table  1.  This  is  the  table  for  the 
wholesale  level  (CCSS  system).  This  table,  like  all  of  the  other  tables, 
has  three  main  columns:  category,  losses  (i.e.  loss  transactions),  and 

loss  recoveries.  The  first  category  is  replacement /consumption  type  1. 

The  table  shows  that  this  category  is  not  applicable  to  the  wholesale  level. 
The  next  category  is  replacement/consumption  type  2.  The  table  shows 
that  issue  transactions  (identified  by  DIC  equal  to  A5-)  are  losses  in 
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CATEGORY 

* 

LOSSES 

| LOSS  REC 

DIC 

! CC 

i MC  j FC  OR  COMHENT 

1 

j DIC 

1 

REPL/CONS 

NOT  APPLICABLE 

1 

N/A 

TYPE  1 

REPL/COHS 

A5- 

M 

TYPE  2 

A5- 

H OR  P 

CJ,  CL,  GQ,  CH 

A5- 

H OR  P 

A.L.Q.S.V 

N/A 

DISPOSAL 

A5- 

NOT 
H OR  F 

CJ 

A5- 

ii 

L.Q.S.V 

D6J 

CONVERSION 

A5- 

NOT 

GH,  CL,  CQ 

D6H 

H OR  P 

D6L 

D6Q 

A5- 

M 

A Suppl.  Add  - A,D 

DBZ(HC-A) 

D9Z 

A 

PROOF  TEST 

A5- 

NOT 
H OR  P 

C 2 

D6G 

D9Z 

M 

... 

• 

... 

TRANSFER 

A5- 

NOT 

NOT  MUST  BE  NON 

D6B 

H OR  P 

A,L,H,Q,S, V ARMY  CONSIGNEE 

D6C 

FUND  CODE  MUST 

D6D 

— - 

NOT  BE  CM 

D6E 

PHYS  INV 

D9A 

D8A 

D9B 

D8B 

D9J 

C8J 

OTHER 

D9G 

DBE 

D9E 

D9H 

TABLE  1 


MATRIX  FOR  WHOLESALE  LEVEL 
(Based  on  AR  725-50) 


LOSSES 


LOSS  RECOVERIES 


! 

i 


l 

DIC 

| cc 

HC 

COMMENT 

DIC 

REPi/CONS 

D9C 

i 

None 

TYPE  1 

D9H 

1 

REPL/CONS 

D7H 

H OR  P 

! 

N/A 

TYPE  2 

D7J 

it 

D7L 

• 1 

D7Q 

• 1 

DISPOSAL 

D7J 

NOT 

D6J 

H OR  P 

CONVERSION 

D7H 

NOT 

; 

Dv'H 

n or  p 

D7L 

D6L 

D7Q 

M 

D6Q 

PROOF  TEST 

D9Z 

M 

; 

D6C 

I 


TRANSFER 

D7B 

, D6B 

D7C 

D6C 

D7D 

D6D 

D7E 

D6E 

D7F 

D6F 

D7C 

D6C 

D7P 

MUST  BE  NON 
ARMY  CONSIGNEE 

. 

D7Z 

it 

PHYS  INV 

D9A 

i 

D8A 

D9B 

D8B 

- - 

D9J 

i 

D8J 

1 

OTHER 

_ 

NONE 

i 

i 

NONE 

TABLE  2: 

MATRIX  FOR  3S  (WEST  PAC) 
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MMI 


\ 


t 


LOSSES 


LOSS  RECOVERIES 


DIC 

• | 

cc 

FC  | 

DIC 

FC 

i 

REPL/CONS 

B9 

PF 

NONE 

Type  1 

B9 

PI 

REPL/CONS 

A5- 

H 

GJ,GH,CL,CQ 

N/A, 

TYPE  2 

A5- 

H 

J5| J6f J7, J8 

J 

69- 

H 

PI 

DISPOSAL 

A5- 

NOT  H 

GJtJ5tJ6 

A6- 

GJf J5, J6 

B2- 

MH 

- 

B3- 

. HH 

CONVERSION 

A5- 

NOT  H 

GHtCLfCQ 

A6- 

CH,GL,GQ 

A5- 

(« 

J7,J8 

A6- 

J7,  J8 

B9 

ii 

PI 

B2- 

CHtGL,MB,MC 

B3- 

GH,GLf  MB,MC 

r * ^ ##  1 

• 

- — *i  — 

PROOF  TEST 

A5- 

C2tJ9 

NONE 

♦ 

TRANSFER 

1 

CBtGCtCD,GE,GP 

CB | GC  t CD | GE | GP 

A5  - 

GA  AND  GZ 

B2*- 

! GA,C9,  MF.,MG 



B3  - 

CA,C9,  ME, MG 

PHYS  INV 

B9 

P9 

E8- 

P8 

OTHER 

NONE 

NONE 

Must  be  receipt  from  or  issue  to  non-Army  source. 


TABLE  3:  MATRIX  FOR  USAMMAE 


24 


! 


LOSSES 


LOS!  RECOVERIES 


I 


CATEGORY 

DIC 

cc 

MC  FC  OR  COMMENT 

i 

DIC 

REPL.CONS 

D9G 

TYPE  1 

D9H 

NONE 

REPL/CONS 

A5- 

M 

TYPE  2 

A5- 

H OR  P 

GJ,GL,GQ,GH 

N/A 



A5- 

M 

A|L|Q»S,V 

DISPOSAL 

A5- 

NOT 

H OR  P 

GJ 

D6J 

A5- 

ii 

L,Q.S,V 

COWERS  ION 

A5- 

NOT 

CH,CL,GQ 

D6H 

H OR  P 

D6L 

D6Q 



A5- 

A SUPPL.  ADD.  - A,D 

D8Z(MC*A) 

PROOF  TEST 

A5- 

NOT 
H OR  P 

G2 

D6G 

D9Z 

M 

TRANSFER 

A5- 

NOT 

NOT  FC  MUST  NOT  BE  GM 

D6B 

H OR  P 

A,L,M,Q,SfV  AND  MUST  BE  NON- 

D6C 

ARMY  CONSIGNEE 

D6D 

D6E 

PHYS  INV 

D9A 

D8A 

D9B 

D8B 

D9J 

D8J 

OTHER 

NONE 

NONE 

TABLE  4:  MATRIX  FOR  SAILS 
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OTHER 


LOSSES 


LOSS  RECOVERIES 


CATEGORY 

DIC 

QIC  COMMENT 

DIC 

REPL/CONS 

62A 

81A 

TYPE  1 

82E 

82F 

REPL/CONS 

51Y 

F OR  J 

N/A 

'TYPE  2 

52Z 

n 

52A 

if 

52B 

ii 

I.-  - 

DISPOSAL 

51V 

NOT 
F OR  J 

21Y 

— - 

52Z 

31Y 

CONVERSION 

52A 

NOT 

22A 

F OR  J 

22B 

52B 

it 

32A 

32B 

PROOF  TEST 

NONE 

NONE 

TRANSFER 

5 2D 

NONE 

52E 

— 

51D 

PHYS  INV 

82B 

8IB 

NONE 


32K 


TABLE  5:  MATRIX  FOR  BASOPS 
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CATEGORY 


I 


DIC  FOR  LOSSES 


DIC  FOR  LOSS 
RECOVERIES 


REPL/CONS 

2M1 

241 

TYPE  1 

BM1 

REPL/CONS 

2N5 

It/A 

TYPE  2 

BN5 

DISPOSAL 

N/A 

255 

CONVERSION 

2M2 

242 

BM2 

B42 

PROOF  TEST 

NONE 

NONE 

TRANSFER 

2N2 

252 

2N3 

253 

BN2 

— 

BN3 

PHYS  INV 

2N6 

256 

— 

BN6 

OTHER 

NONE 

NONE 

TABLE  6:  MATRIX  FOR  NATIONAL  GUARD 


CATEGORY 

TRANSACTION  CODE 

1 TRANSACTION  code 

FOR  LOSSES 

j FOR  loss  recoveries 

REPL/CONS 

» 

04 

1 

NONE 

TYPE  1 

07 

08 

REPL/CONS 

54 

N/A 

TYPE  2 

DISPOSAL 

N/A 

i 

M 

CONVERSION 

45 

15 

YY 

YY 

PROOF  TEST 

NONE 

NONE 

TRANSFER 

41 

N/A 

46 

47 

PHYS  INV 

03 

02 

OTHER 

55 

NONE 

TABLE  7:  MATRIX  FOR  CCSS-ISA 
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LOSSES 


CATEGORY 

DIC 

FC  SERV.  CODE 

' DIC  FOR  LOSS 

IN  SUPPL.  ADDR 

RECOVERIES 

REPL/CONS 

D9C 

NONE 

TYPE  1 

D9H 

REPL/CONS 

A5- 

CJ 

N/A 

TYPE  2 

A5- 

SEE  NOTE  S 

DISPOSAL 

N/A 

D6J 

CONVERSION 

A5- 

GL 

D6L 

PROOF  TEST 

D9Z 

(EDIT  CODE  IS  M) 

NONE 

TRANSFER 

A5- 

GA  NGN-ARMY 

CONSIGNEE 

A5- 

GB 

NONE 

A5- 

GC 

A5- 

GD 

- . - .. 

A5- 

GE 

PHYS  INV 

D9A 

i 

D8A 

D9B 

D8B 

— 

D9J 

D8J 

OTHER 

NONE 

NONE 

NOTES  FUND  CODE  IS  NOT  GA,GB,GC,GD, GE,GJ,GL  OR  BLANK 


TABLE  8:  MATRIX  FOR  SPEEDEX-ISA 


! 

LOSSES 

1 

CATEGORY 

Die 

j CC 

♦ 

i 

DIC  FOR  LOSS  RECOVERIES 

REPL/CONS 

Z4F 

I 

Z6F 

Z4J 

TYPE  i 

Z4K 

t 

REPL/CONS 

Z7N 

H OR  P 

• 

TYPE  2 

Z4C 

II 

N/A 

DISPOSAL 

Z7N 

NOT 

Z3N 

H OR  P 

CONVERSION 

Z4G 

NOT 

Z6C 

— 

H OR  P 

... 

PROOF  TEST 

NONE 

NONE 

TRANSFER 

NONE 

Z3R 

PHYS  INV 

Z4B 

76B 

OTHER 

NONE 

-3H 

table  9:  matrix  for  team  up-isa 
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one  of  three  cases: 

a.  The  management  code  is  M.  The  values  of  the  condition  code 
and  fund  code  are  immaterial  in  this  instance. 

b.  The  condition  code  is  H or  P (indicating  uneconomlcally 
reparable  condition)  and  the  fund  code  is  CJ,  CLt  CQ,  or  GH.  The  value 
of  the  management  code  is  immaterial  in  this  instance. 

c.  The  condition  code  is  H or  P and  the  management  code  is 

A,  L,  Q,  S,  or  V.  The  value  of  the  fund  code  ia  immaterial  in  this  Instance. 
The  table  also  shows  that  replacement/coneumption  type  2 is  not  applicable 
to  loss  recoveries. 

The  next  category  is  disposal.  An  issue  to  PDO  is  a disposal  loss 
only  if  the  condition  code  is  not  "H"  or  MP".  In  addition,  the  transaction 
must  have  either  a fund  code  equal  to  GJ  and/or  a management  code  equal  to 
L,  Q,  S,  or  V.  If  the  document  identifier  code  is  a ”D6J",  the  transaction 
is  a loss  recovery  from  PDO  and  ia  thus  ~oded  DISPOSAL. 

Reading  the  table  for  the  remaining  categories  is  similar. 

2.7  Approximations 

In  developing  the  tables  in  the  previous  section,  approximations 
were  used.  The  approximations  are  necessary  because  the  ADP  systems  that 
feed  transaction  data  have  limited  coding  structures.  For  example,  MILSTRIP 
iosue  transactions  to  PDO  have  no  data  element  from  which  the  reason  for 
the  issue  (e.g.  stock  is  uneconomlcally  reparable  due  to  an  act  of  God  such 
as  flooding  or  lightning,  or  fair  wear  and  tear,  or  proof  testing,  etc.) 
can  be  determined.  Expanding  the  ADP  systems  to  provide  the  appropriate 
data  would  require  extensive  system  changes  Army  wide.  Doing  this  would 
not  only  be  costly  but  Is  unnecessary  because  harmless  approximations  can 
be  used.  These  approximations  are: 

a.  All  issue  transactions  to  PDO  and  to  assembly/dlsaaaembly/ 
nodificat ion/conversion  are  replacement/consumption  type  2 losses  whenever  - 

(1)  there  is  a data  element  in  the  transaction  to  indicate 
that  the  stock  issued  is  uneconomlcally  reparable,  or 

(2)  there  is  no  data  element  to  indicate  the  condition  of  the 

stock  issued. 
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b.  If  the  loss  adjustment  transaction  is  not  a logistic  transfer, 
catalog  change,  nodif ication/conversion  adjustment,  or  physical  inventory 
adjustment,  then  it  is  - 

(1)  replacement/consumption  type  1 loss  if  the  adjustment 
is  to  be  property  account  below  the  wholesale  level,  and 

(2)  "other”  loss  if  the  adjustment  is  to  a wholesale  level 
property  account. 

Approximation  a(l)  says  that  all  unccononically  reparable  stock  that 
leaves  the  Army  inventory  is  replacenent/consumption  type  2.  Most  of  it 
will  be.  However,  occasionally  the  stock  will  be  uneconomlcally  reparable 
due  to  damage  caused  by  some  act  of  Cod  (e.g.  earthquake,  tornado)  or 
proof  test  damage.  In  these  instances  the  loss  will  be  miscoded.  The 
consequence  of  miscoding  will  be  to  increase  the  replacement/consumption 
factor.  The  Increase  will  be  insignificant  unless  the  quantity  damaged 
by  the  act  of  God  or  proof  testing  is  large  in  relation  to  total  disposals 
of  uneconomlcally  reparable  stock.  This  is  unlikely  except  in  rare 
Instances  such  as  500  trucks  damaged  by  flood.  In  such  Instances,  the 
item  manager  will  have  first  hand  knowledge  to  recode  these  losses.  Thus, 
this  approximation  is  harmless  because  there  are  no  serious  consequences. 

Approximation  a (2)  says  that  all  Issues  to  PDO  or  asaembly/dlsassembly 
are  replacement/consumption  type  2 losses  if  the  is  from  a praperty 

account  that  is  on  an  ADP  system  that  lacks  a condition  code.  All  ADP 
systems  above  the  field  level  and  some  AIP  systems  at  tht  field  level 
use  a condition  code  for  stock  accounting.  Thus,  this  approximation  is 
applicable  to  only  a few  field  level  ADP  systems  (e.g.  modified  DLOGS  used 
by  National  Guard).  For  these  accounts,  disposals  of  serviceable  or  un- 
serviceable but  economically  reparable  stocks  will  be  miscoded.  It  is 
expected  that  few,  if  any,  transactions  would  be  involved  be  iuoe  AR  710-2 
prohibits  disposals  of  serviceable  or  unserviceable  economically  reparable 
major  items  at  thi9  level.  If  there  are  any  such  transactions,  the  impact 
(i.e.  inflated  replacement/consumption  factor)  would  be  significant  only 
if  large  quantities  are  Involved.  Again,  if  this  ever  occurs,  the  Item 
manager  would  have  first  hand  knowledge  to  recode.  Thus,  this  approximation 
is  also  harmless. 
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Approximation  b (1)  applies  to  non-depot  stocks  that  might  be  completely 
destroyed  (i.e.  no  remains)  by  enemy  action,  fire,  or  some  act  of  Cod,  and 
to  losses  due  to  theft,  abandonment,  etc.  Host  of  these  losses  are 
generally  accepted  as  replacement/consumption.  Those  that  are  not  will 
be  miscoded  but  the  anticipated  incidence  of  miscoding  is  very  small 
and  insignificant.  Consequently  this  approximation  is  harmless. 

Approximation  b(2)  has  no  impact  other  than  to  assign  the  loss  category 
"other"  to  some  losses  that  may  be  physical  inventory  losses.  This  is 
harmless. 
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CHAPTER  III 


PROPOSED  SYSTEM  FOR  USER  ACCOUNTS 

3.1  General 

This  chapter  applies  to  user  property  accounts,  be  they  manual  or 
automated.  User  property  accounts  are  the  accountable  property  records 
at  the  user  level.  They  Include  property  books  held  by  units  such  as 
company  or  battalion  and  stock  record  accounts  of  direct  support/general 
support  units.  However,  they  exclude  hand  receipt  holders.  This  means 
that  if  the  accountable  property  records  for  all  equipment  vrlthin  a 
division  are  maintained  at  the  division  level,  there  would  ba  only  one 
account  for  the  entire  division  to  which  the  procedures  of  this  chapter 
are  applicable,  even  though  the  various  sub-elements  of  the  division  such 
as  battalions  may  have  their  own  records  for  the  equipment  In  their 
possession. 

The  objective  of  this  chapter  Is  to  discuss  a system  to  provide 
auditable  loss/loss  recovery  data  from  the  user  level  property  accounts. 

At  the  present  time  the  CBS  system  does  not  Include  transaction  data 
reporting  from  these  accounts.  Consequently,  the  loss/loss  recovery  data 
obtained  by  the  methods  of  the  previous  chapter  will  be  Incomplete.  A 
supplement  Is  needed  to  provide  the  missing  data. 

This  chapter  discusses  how  to  provide  CBS  with  transaction  data  from 
the  user  property  accounts  and  how  to  process  these  transactions  for  loss/ 
loss  recovery  purposes. 

3*2  Required  User  Level  Data 

Proof  test  and  transfer  loss  categories  are  not  applicable  to  the 
user  accounts.  Applicable  categories  are  replacement  consumption  type  1 
and  type  2,  disposal,  conversion,  physical  Inventory,  and  others.  To  get 
all  user  level  losses  and  loss  recoveries  and  to  classify  them  Into  the 
applicable  categories  requires  the  Information  specified  herein. 

For  CBS  and  loss/loss  recovery  purposes  the  following  transactions 
are  needed: 

a.  Turn  In  to  property  disposal  (PDO) 
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b.  Receipt  from  property  disposal  (PDO) 

c.  Receipt  of  stock  found  on  post  (FOP) 

d.  Adjustments  due  to 

(1)  modification. 

(2)  physical  inventory. 

(3)  other. 

e.  Lateral  transfers  to/from  another  CBS  stratification  (data 
clement  J in  Section  2.5).  They  are  needed  for  CBS  purposes  only. 

Adjustments  due  to  other  (d(3)  above)  include  all  adjustment  trans- 
actions that  require  a discrepancy  in  shipment  report,  or  a report  of 
survey,  or  non-physical  inventory  adjustments  that  require  an  inventory 
adjustment  report.  They  are  replacement/consumption  type  1 losses. 

The  transactions  should  have  these  data  elements: 

a.  Identification  of  the  base  account  (account  to  vhlch  the 
transactions  apply). 

b.  Identification  of  the  supporting  account  (account  that  feeds 
the  data  for  the  base  account) . 

c.  National  Stock  Number 

d.  Transaction  date 

e.  Document  or  voucher  number  (this  data  element  will  provide 
intransit  visibility).  Applicable  to  lateral  transfer  only. 

f.  Organization  identification  of  the  terminal  account,  etc. 
This  is  the  consignee  of  stock  shipped  or  source  of  stock  received  and 
is  applicable  to  lateral  transfers  only. 

g.  Code  to  indicate  if  transaction  is  gain  (Increase),  loss 
(decrease)  or  reversal  to  base  account. 

h.  Code  to  indicate  if 

(1)  receipt  of  stock  found  on  post  (FOP). 

(2)  receipt  from  PDO/turn  in  to  PDO. 

(3)  adjustment  due  to  modification. 

(4)  adjustment  due  to  physical  inventory. 

(5)  adjustment  due  to  other  (category  does  not  Include 

catalog  changes) • 

(6)  lateral  transfer  (in  or  out). 
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1.  Condition  code 

(1)  serviceable. 

(2)  unserviceable. 

3.3  Automated  Accounts 

Some  user  accounts  are  now  automated.  It  is  expected  that  in  the 
near  future  all  U6er  accounts  will  be  automated.  For  example,  SADLS  is 
a standard  system  for  all  divisional  level  units.  DS4  is  a standard 
system  for  all  non-dlvlslonal  level  units.  Both  of  these  systems  are 
currently  in  developmental  stages. 

Automated  systems  can  provide  transaction  data  in  standard  format 
(see  3.2  for  the  data  elements  to  be  entered  in  the  transactions).  A 
minor  program  is  needed  to  scan  the  transaction  file  available  in  a partic- 
ular automated  system  and  recode  and  reformat  the  data  into  the  standard 
format.  A suitable  procedure  for  submitting  the  standard  transaction 
data  to  HIDA  can  be  worked  out.  For  example,  each  automated  system  can 
forward  the  standard  data  to  the  command  level  for  consolidation  and  sub- 
sequent forwarding  to  MIDA. 

3.4  Manual  Accounts 

The  procedures  discussed  here  are  interim.  When  a manual  account  is 
automated,  it  should  adopt  the  procedures  in  3.3. 

Transaction  data  for  a manual  account  can  be  had  directly  from  the 
property  record  or  in  some  indirect  way.  The  alternative  discussed  in 
3.4.1  la  the  direct  way.  The  alternative  discussed  in  3.4.2  is  one  in- 
direct way.  In  3.4.3  ve  discuss  the  advantages  and  disadvantages  of  the 
two  alternatives. 

3.4.1  Alternative  One;  Property  Record  Reporting 

The  steps  in  property  record  reporting  are  these: 

a.  Copy  of  page  from  official  property  record  is  submitted 
to  some  processing  point  (e.g.,  division  level).  The  page  submitted  would 
be  the  one  that  has  the  transactions  for  the  reporting  period. 
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b.  Processing  point  prepares  (i.e.  keypunches)  standard 
records  for  the  transactions  specified  in  3.2  in  the  format  specified 

in  last  section  and  forwards  the  data  to  Command  level  for  consolidation. 

c.  Each  Command  consolidates  these  data  and  forwards  to 

MIDA. 

d.  MIFA  processes  the  data  as  discussed  in  3.5. 

Suitable  controls  should  be  established  to  police  reporting. 

To  make  this  sytem  work,  property  books  (DA  Form  3328  and 

DA  Form  3329)  should  be  modified  to  include  columns  for  Mgain  adjustment", 
''loss  adjustment",  and  "comment".  The  stock  record  account  (DA  Form  1296) 
should  be  modified  to  Include  the  unit  identification  code  of  the  account, 
and  a "comment"  column.  The  columns  on  the  property  records  should  then  be 
used  to  post  transactions  as  follows: 

a.  If  the  transaction  is  actually  a turn  in,  enter  quantity 
turned  in  in  the  "turn  in"  column. 

b.  If  me  transaction  is  a receipt,  enter  quantity  received 
in  the  "received"  column. 

c.  If  the  transaction  is  an  adjustment  that  increases  the 
balance  (i.e.  no  receipt)  enter  the  quantity  in  the  "adjusted  gain"  column. 

d.  If  the  transaction  is  an  adjustment  that  decreases 

the  balance  (i.e.  no  turn  in)  enter  the  quantity  in  "adjusted  loss"  column 

e.  If  the  turn  in  is  to* PDO  or  the  receipt  is  from  PDO 
enter  "PDO"  in  the  "comment  column". 

f.  If  the  transaction  is  a lateral  transfer,  enter  "STRAT 
(XXXXXX)  in  the  "comment"  column,  where  XXXXXX  is  the  UIC  of  the  other 
account. 

g.  If  the  transaction  is  an  adjustment,  enter  the  applicable 

one  of  these  four  comments  ir.  the  "comment"  column:  MODIFICATION,  PHYS  INV, 

CATALOG  CHANGE,  OTHER.  The  comment  "catalog  change"  should  be  used  for 
catalog  change  adjustments  to  make  it  clear  that  the  adjustment  is  not  a 
loss  • 

3.4.2  Alternative  Two:  DIO  Generation  of  Transactions 


The  steps  in  this  alternative  are  these: 
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a.  Property  account  informs  the  applicable  activity  in 
the  Directorate  of  Industrial  Operations  (DIO)  of  those  entries  to  the 
user  property  account  that  are  d*ie  to  receipt  of  stock  found  on  post 
and  modification.  This  is  done  on  an  "as  occur"  basis. 

Note:  Under  present  procedures  the  DIO  is  cognizant  of  all  adjust- 

ments to  the  property  account  that  require  a report  of  survey * inventory 
adjustment*  or  discrepancy  in  shipment  report.  He  is  also  cognizant 
of  d'-oosal  and  lateral  transfer  transactions  because  they  must  be  approved 
at  this  level.  This  information  combined  with  the  information  that  would 
be  reported  to  the  DIO  under  step  a.  is  all  that  is  needed  to  prepare  the 
transactions  needed  for  CBS  (see  3,2), 

b.  The  applicable  DIO  activity  prepares  a standard  record 
as  specified  in  3,2  and  enters  it  in  the  intermediate  level  transaction 
history  file.  This  is  done  whenever  the  DIO  receives  information  that 
impacts  the  balance  in  the  user  property  account, 

c.  The  intermediate  level  transaction  history  is  forwarded 
to  MIDA  as  is  currently  done.  The  only  difference  is  that  now  the  trans- 
action history  has  user  level  transactions  as  well, 

d.  MIDA  extracts  user  transactions  and  processes  as  in 

3.3. 

3.4.3  Comparative  Analysis 

|| 

Both  alternatives  require  the  same  amount  of  keypunching  since 
each  should  provide  the  same  number  of  transactions  to  MIDA.  However* 
the  keypunch  workload  is  peacemeal  for  the  DIO  generation  of  transactions 
alternative  and  this  is  an  advantage. 

Property  record  reporting  requires  hard  copy  Inputs  (l.e.  copy 
of  page  from  property  record)  from  the  user.  This  type  of  reporting  can  be 
readily  controlled.  The  DIO  generation  of  transactions  requires  some  input 
(i,e.  adjustments  due  to  modification  and  receipts  of  stock  found  on  post) 
from  the  user.  This  can  be  provided  in  hard  copy  form  or  by  telephone* 

but  in  either  case  it  would  be  difficult  to  establish  controls  that  would  ^ 

guarantee  valid  inputs  from  the  user.  If  the  two  types  of  transaction 
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inputs  from  the  user  occur  very  infrequently,  it  might  be  acceptable 
to  Ignore  these  transactions  altogether.  In  r hat  event,  the  DIO  generation 
of  transactions  would  have  an  advantage  over  property  record  reporting,  since 
It  would  require  no  input  from  the  user. 

Property  record  reporting  would  provide  highly  reliable  and  fully  audit- 
able  data,  since  the  source  data  is  the  official  property  record.  There 
nay  be  some  errors  in  transcribing  the  data  into  transactions  but  these 
types  of  errors  are  relatively  few.  The  DIO  generation  of  transactions 
would  be  less  reliable  and  less  auditable  than  property  record  reporting. 

The  DIO  generation  of  transactions  requires  no  changes  tc  AR  710-2 
whereas  property  record  reporting  does  (must  change  DA  Form  3328,  DA  Form  3329, 
and  DA  Form  1296).  However,  changing  -.he  property  record  forms  to  satisfy 
CBS  and  loss/loss  recovery  needs  has  worthwhile  byproducts.  It  would  improve 
record  keeping  for  the  user.  At  time  of  local  command  inspections,  IC  in- 
spections, and  audit  by  AAA  or  GAO,  the  better  organized  property  records 
would  be  self  sufficient.  The  reason  for  a change  in  the  record  balance 
would  be  evident  from  the  property  record.  Today,  to  determine  the  reason 
it  is  necessary  to  search  through  various  backup  folders  such  as  the  manual 
transaction  file. 

Another  worthwhile  byproduct  of  property  record  reporting  is  elimination 
of  the  need  for  user  Inputs  in  support  of  equipment  status  reporting 
(Chapter  2,  AR  710-3).  Today,  asset  status  updating  requires  interaction 
between  the  user  and  the  Data  Processing  Installation  (DPI)  that  supports 
him.  (See  Chapter  2,  AR  710-3)  Furthermore,  the  validity  of  the  asset 
data  are  questionable  because  the  update  procedures  lack  adequate  controls. 
Instead  of  these  procedures,  the  asset  balance  as  of  any  given  date  can  be 
taken  directly  from  the  property  record  at  the  time  the  transactions  are 
prepared  for  CBS  and  loss/loss  recovery  purposes.  This  procedure  would 
provide  reliable  user  equipment  status  reports  to  MIDA.  The  asset  data  would 
be  compatible  with  the  transaction  data. 

3.3  MIDA  Processing 

The  processing  at  MIDA  would  be  similar  to  the  processing  described  in 


39 


Chapter  2.  The  transactions  would  be  input  to  a pre-processor  to  generate 
standard  CBS  records.  The  output  would  be  consolidated  with  the  standard 
CBS  records  from  all  the  other  pre-processors.  These  consolidated  trans- 
actions would  then  be  input  to  the  loss/loss  processor  to  generate  the 
loos  data  file.  The  loss/loss  recover:/  processor  would  use  Tables  3.5.1 
and  3.5.2  to  assign  loss  categories  to  the  user  level  transactions. 

Table  3.5.1  applies  to  transactions  from  the  property  book  accout ts. 

The  column  headings  should  not  be  taken  literally.  For  example,  "turn-in” 
is  used  because  it  appears  on  the  property  book  (DA  Form  3328  and  DA  Form 
3329).  The  column  is  intended  to  represent  issue  (as  opposed  to  adjustment) 
transactions.  The  "X"  indicates  that  there  is  an  entry  in  that  field.  A 
blank  indicates  that  the  data  element  is  immaterial  for  assigning  & category 
to  the  transaction.  For  example , the  table  shows  that  a replacement  con- 
sumption type  1 loss  is  any  transaction  that  has  an  entry  in  the  "adjusted 
loss"  column  and  the  word  "other"  in  the  comment  column.  Replacement/ 
consumption  type  2 loss  is  any  transaction  that  has  an  entry  in  the  turn  In 
column  and  "PDO"  in  the  comment  column.  This  assumes  that  the  condition 
code  for  the  materiel  turned  in  is  not  reported.  This  assumption  is  made 
because  the  property  book  does  not  show  the  condition  code.  If  the  con- 
dition code  were  reported,  the  transaction  would  be  coded  replacement/con- 
sumptlon  type  2 if  the  condition  code  were  U (unserviceable)  and  disposal 
if  the  code  were  S (serviceable). 

Table  3.5.2  applies  to  transactions  from  the  stock  record  accounts. 

The  organization  column  is  used  to  distinguish  adjustment  transactions  from 
Issue/receipt  transactions.  If  there  is  no  entry  in  the  organization  column 
(l.e.  it  is  blank),  the  transaction  is  an  adjustment.  Thus,  for  example, 
an  entry  (X)  in  the  loss  column  and  a blank  in  the  organization  column  is 
a lose  adjustment.  The  type  of  loss  is  known  from  the  comment  column.  If 
the  comment  is  "other",  the  loss  is  replacement /consumption  type  1;  if  it 
is  "modification",  the  los9  is  conversion;  if  it  is  "phys  inv",  the  loss 
category  is  physical  inventory.  On  the  other  hand,  an  entry  (X)  in  the  loss 
column  and  an  entry  in  the  organization  column  is  an  issue  transaction. 
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TABLE  3.5.1 : MATRIX  FOR  PROPERTY  BOOK  RECORDS 


i 


CATEGORY 

' 

LOSSES 

| 

1 

* 

LOSS  RECOVERIES 

TURNED 

IN 

ADJUSTED 

LOSS 

COMMENT 

RECEIVED  ADJUSTED 

1 GAIN 

1 

COMMENT 

REPL/CONS 
TYPE  1 

X 

OTHER 

X 

X 

OTHER 

FOP 

REPL/CONS 
TYPE  2 

X 

POO 

DISPOSAL 

NOT  APPLICABLE 

X 

PDO 

CONVERSION 

X 

MODIFICATION 

X 

MODIFICATION 

PHYS  INV 

X 

PHYS  INV 

X 

PHYS  INV 

TABLE  3.5.2:  MATRIX  FOR  SRA  RECORDS 


CATEGORY 

i 

LOSSES 

! 

| 

LOSS  RECOVERIES 

ORGAN- 

IZATION 

LOSS 

CONDITION 

COMMENT 

ORGAN-  ' GAIN 

IZATION 

COMMENT 

REPL/CONS 
TYPE  1 

BLANK 

X 

OTHER 

BLANK  X 

X 

OTHER 

FOP 

REPL/CONS 
TYPE  2 

X 

X 

U 

PDO 

NOT  APPLICABLE 

DISPOSAL 

X 

X 

S 

PDO 

X x 

PDO 

CONVERSION 

BLANK 

i 

X 

i 

MODIF- 

ICATION 

BUNK  X 

MODIF- 

ICATION 

PHYS  INV 

j 

• BLANK 

X 

l 

i 

PHYS  INV 

RI.ANK  ? Y PHYS  INV 
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CHAPTER  IV 
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OTHER  CONSIDERATIONS 

4.1  Introduction 

The  proposed  system  Is  transaction  dependent.  The  quality  of  the 
loss/loss  recovery  data  will  depend  on  the  quality  of  the  transaction  data 
and  on  correct  interpretation  of  the  transactions.  If  a loss  occurs  but 
there  is  no  transaction  for  it,  or  there  is  a transaction  but  it  is  not 
properly  coded,  this  loss  will  not  be  on  the  loss  data  file.  If  a loss 
occurs  but  there  are  two  transactions  to  cover  it,  the  system  will  pick 
up  this  loss  twice.  There  are  operational  system  deficiencies  that  can  lead 
to  such  voids  and  duplications.  This  chapter  addresses  the  problem  areas. 

4.2  En  Route  Losses 

AR  735-11  prescribes  procedures  for  en  route  losses.  The  regulation 
addresses  the  financial  aspect  of  the  loss  but  not  the  supply  aspect. 

Neither  this  nor  any  other  regulation  provides  a supply  transaction  ^ 

to  show  the  en  route  loss.  This  is  not  too  critical  when  the  loss  is 

stock  that  is  en  route  to  a non- Army  customer  because  the  loss  is  picked 

up  from  the  issue  transaction.  For  CBS  purposes  this  is  adequate.  For  loss / 

loss  recovery  purposes  this  is  also  adequate  except  that  the  loss  will  be 

miscoded  ( coded  "transfer"  instead  of  "other") . The  impact  of  miscoding 

will  not  be  significant  unless  the  quantity  involved  is  sufficiently 

large  to  appreciably  rAise  the  variability  of  transfer  losses.  However, 

if  the  quantity  Involved  is  this  large,  the  item  manager  will  have  first 

hand  knowledge  to  recode.  In  fact,  he  will  be  alerted  to  the  need  for 

recoding  because  the  transfer  losses  for  the  period  involved  will  stand 

out  in  comparison  to  the  past  transfer  losses. 

When  the  loss  is  stock  that  is  en  route  to  an  Army  customer, 
this  loss  will  not  be  picked  up  from  the  transaction  history.  What  is 
needed  13  a procedure  to  provide  a supply  transaction  for  losser  en  route 
to  Army  customers.  Under  the  current  procedures  when  a loss  occurs, 
a report  of  survey  is  prepared  and  processed  through  the  transportation 
channels.  Ft.  Benjamin  Harrison  sends  notification  to  the  applicable 
Finance  and  Accounting  Branch  where  the  customer  billing  is  adjusted. 

No  notification  is  sent  to  the  Supply  Branch.  A satisfactory  procedure 
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would  be  to  have  either  Ft.  Benjamin  Harrison  uotify  the  Supply 
Branch  as  well,  or  to  have  the  Finance  and  Accounting  Branch  work  with 
the  Supply  Branch.  The  Supply  Branch  would  then  enter  an  applicable 
transaction  on  the  history  file  to  show  the  loss.  AR  735-11  could  be 
modified  accordingly.  However,  before  any  modifications  are  made  to  thle 
or  other  applicable  regulations,  It  should  be  remembered  that  there  are 
two  situations  for  en  route  losses  to  Army  customers:  the  whole  shipment 

Is  lost;  there  is  a discrepancy  between  the  shipping  document  and  the 
quantity  actually  received.  In  the  latter  case  there  Is  danger  of  double 
counting  unless  the  reguljpion  clearly  states  at  which  end  (l.e.  supplier 
or  customer)  discrepancy  Is  to  be  posted.  It  la  suggested  that  If  the  loss 
Is  merely  a discrepancy  between  the  shipping  document  and  the  materiel 
received,  the  customer's  account  reflect  th*  loss.  If  the  whole  shipment 
is  lost,  the  supplier's  account  should  reflect  the  loss.  AR  735-11  should 
clearly  state  this.  This  should  also  be  specifically  mentioned  In 
AR  710-2  in  paragraphs  3-40b,  3-71  and  in  paragraph  2-12. 

Although  existing  accounting  systems  (except  BASOPS  and  TEAM-UP)  do 
not  have  DIC's  for  en  route  losses,  new  DIC’s  are  not  needed.  This  Is 
because  en  route  losses  at  the  wholesale  level  are  "other",  and  below 
the  wholesale  level  are  replacement/consumptions  type  1.  Consequently, 
any  existing  DIC  to  which  approximation  2.7.b  applies  could  be  used  to 
adjust  for  en  route  losses. 

4.3  Incompatible  Document  Identifier  Codes  (DIC's) 

Codes  "D9G"  and  "D9H"  in  MILSTRIP  based  systems,  and  comparable 
codes  in  non-MILSTRIP  based  systems,  are  incompatible  and  each  can  lead  to 
duplications.  For  example,  "D9G"  transaction  is  for  losses  due  to  shrinkage, 
theft,  contamination,  deterioration.  Shrinkage  and  theft  are  cases  of  dis- 
appearance while  contamination  and  deterioration  are  not.  For  contamination/ 
deterioration  a "D9G"  adjustment  still  leaves  materiel  behind  that  can  be 
transferred  to  PDO  and  picked  up  as  a loss  once  more  from  the  transaction 
that  transfers  the  stock  to  PDO.  Thus,  there  Is  danger  of  double  counting 
the  loss. 
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This  problem  can  be  resolved  without  changes  to  present  accounting 
systems  (e.g.  MILSTRAP).  It  merely  requires  restricted  use  of  the  codes. 

This  can  be  accomplished  by  such  means  as  a circular  applicable  to  property 
accounts  at  all  levels  (i.e.  NICP's,  FORSCOM/TRADOC  installations,  over- 
seas ICP’s,  all  other  installations  and  property  accounts).  The  guidance 
should  be  a part  of  the  standard  operating  procedures.  The  guidance  is 
this:  do  not  use  adjustment  transactions  (as  opposed  to  issue  transactions) 

to  decrease  the  stock  balance  when  there  is  still  materiel  left  behind 
that  can  be  disposed  of  at  a later  time.  Decrease  the  balance  by  virtue 
of  an  issue  transaction  at  time  of  disposition.  For  example,  in  KILSTRIP 
based  systems,  the  MD9G"  transaction  should  be  used  to  adjust  for  theft 
and  shrinkage  but  not  for  contaninatlon/deterioratlon.  If  contaminated 
or  deteriorated  stock  is  discovered  by  the  storage  activity,  the  '*DACM 
transaction  with  the  applicable  management  code  should  be  used  to  notify 
the  accountable  activity.  The  accountable  activity  can  then  use  the  "DAC" 
transaction  to  generate  an  MA5-"  transaction  to  decrease  the  stock  balance. 
Another  example  is  a transaction  that  decreases  the  stock  balance  due  to 
fire,  flood,  snow  damage,  etc.  This  transaction  should  be  used  only  when 
there  are  no  remains. 

4.4  Nonstandard  Use  of  Codes 

In  some  Instances  the  NICP*s  differ  in  the  way  they  code  a transaction 
to  account  for  a loss.  They  use  different  DIC*s,  or  the  same  010*8  but 
different  fund  codes  and  management  codes.  Because  use  of  codes  differs, 
whereas  the  pre-processor  does  not  (the  wholesale  level  pre-processor 
is  used  to  process  transactions  from  all  the  NICP’s  on  ALPHA)  duplications 
and  voids  may  arise. 

To  correct  this  deficiency  action  is  required  to  determine  what 
guidance  the  NICP's  have  cn  the  use  of  these  DIC*s  in  the  ALPHA  system  and 
then  modify  the  wholesale  level  (i.e.  ALPHA)  pre-processor  accordingly.  If 
it  is  found  that  there  is  no  guidance,  it  should  be  furnished.  The  guidance 
below  which  tlso  encompasses  some  of  the  other  problem  areas  of  this  chapter, 
is  suggested  in  that  event.  Incidentally,  the  problem  of  nonstandard  use 
of  codes  is  prevalent  at  all  levels.  Guidance  similar  to  the  guidance  below 
should  be  given  to  users  of  SAILS  and  to  those  responsible  for  developing 
the  SADLS  and  DS4  systems  and  SOP's. 
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(1)  Use  of  fund  code,  management  code,  and  condition  code  is 
mandatory  in  all  transactions  that  provide  for  these  data  elements. 

(2)  Use  of  D7-  transactions  is  not  authorized. 

(3)  For  major  items  only  fund  codes  included  in  Appendix  0-2, 

AR  725-50  are  authorized.  Definitions  of  fund  codes  indicated  therein 
must  be  complied  with. 

(4)  The  D9-  series  documents  are  authorized  only  for  "stock 
disappearance"  type  losses.  Examples  are  theft,  discrepant  posting, 
complete  annihilations,  and  any  other  loss  for  which  there  is  no  materiel 
that  could  be  turned  in  to  disposal. 

(5)  D9Z  and  D8Z  are  to  be  used  only  with  authorized  management 
codes.  The  authorized  management  codes  are: 

A - Modified  to  new  NSN  in  maintenance 

(6)  Reversal  transactions  are  to  be  coded  as  specified  in 
Appendix  B of  AR  725-50.  No  other  procedure  is  authorized. 

(7)  A5-  transactions  must  be  used  for  proof  test/saznpling, 
asscmbly/disassembly/modifications/conversion,  property  disposal,  training, 
and  any  other  losses  where  movement  of  materiel  is  involved  prior  to  the 
loss • No  other  transactions  are  authorized. 

Item  (5)  may  be  incomplete.  The  NICP’s  should  suggest  additional 
management  codes  for  the  guidance,  as  necessary. 

4.5  SAILS  Pre-Processor 

SAILS  has  undergone  several  changes  since  the  pre-processor 
was  written.  Foremost  among  the  changes  is  the  extension  of  SAILS  to  the 
ICP  level  overseas.  This  means  that  depot  level  transactions,  which  were 
not  applicable  to  SAILS  users  before  this  extension  are  now  applicable. 
Consequently,  if  the  pre-processor  is  not  modified  accordingly,  some 
loss/loss  recovery  transactions  will  be  bypassed. 

Here  are  two  specific  changes  that  are  required: 

(1)  Add  all  transactions  that  are  applicable  to  depot  level 
such  as  receipts  and  Issues  from  non-Army  customers.  Fund  codes  CD,  GE,  GP, 
GQ,  and  G2  are  applicable. 
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(2)  Add  the  "D9J"  transaction  to  reflect  the  latest  DIC 
structure  in  AR  725-50. 

Incidentally,  the  pre-processor  for  the  wholesale  level  (i.e.  ALPHA) 
and  the  pre-processor  for  SAILS  should  be  essentially  the  same  since  both 
systems  are  MILSTRIP  based.  If  there  are  differences  they  should  be  due 
to  non-standard  use  of  MILSTRIP  codes  at  the  wholesale  and  intermediate 
levels. 

4.6  Asset  Reporting  Under  Chapter  2,  AR  710-3 

Chapter  2 of  AR  710-3  describes  the  Army  Equipment  Status  Reporting 
(see  reference  (2)).  Paragraph  2-13. b.  of  the  regulation  specifies  that 
uneconomlcally  reparable  stock  should  not  be  reported.  If  such  stock  is 
not  reported  but  retained  by  the  reporting  account,  there  will  be  disagree- 
ment between  the  CBS  computed  WWAP  and  the  reported  WWAP.  This  paragraph 
should  be  changed  to  include  uneconomlcally  reparable  stock  in  the  reporting 
of  assets.  These  assets  are  not  lost  as  long  as  they  are  in  the  system. 

In  some  instances,  such  as  for  purposes  of  AMP,  it  may  be  desirable  to  con- 
sider them  lost.  However,  the  proper  way  to  accomplish  this  is  to  show  them 
as  memo  entries  on  the  AMP  and  not  to  ignore  them  entirely  by  excluding 
them  from  the  asset  reports. 
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